fix: handle postgres pgvector table layout - #2748
Conversation
|
Verified locally. The pgvector/Postgres fix looks good, but I think this needs one change before merge. The new global config: regresses array literals outside Postgres. For example, on this PR:
is fixed to:
for BigQuery, SparkSQL, and DuckDB. On main, those preserve the space. Could we scope the The rest looks solid: |
e013875 to
7507d8f
Compare
7507d8f to
00818b8
Compare
|
Thanks for catching this. I agreed that the I also added regression coverage for |
|
This is already partially solved with the correct config as well. Did we consider that? Looking at your query, though, I think there are still some improvements that we should make. It might be worth just breaking them up a little. |
Ah I see - with I’ve split the remaining formatter changes into smaller draft PRs:
I think we can treat this PR as superseded by those smaller PRs and review whichever fixes still make sense independently. |
PostgreSQL pgvector table formatting should preserve the expected layout for CREATE TABLE statements that combine extension-style vector columns, array types, table constraints, and partition clauses.
The current Postgres formatting path treats pgvector-style
vector(...)and adjacent bracketed syntax too broadly, so reflow inserts spaces into PostgreSQL type/reference syntax and removes expected continuation indentation from table constraints. This change gives the parser and reflow config more precise segment types for these constructs sovector(1536),TEXT[], andREFERENCES table(column)keep their PostgreSQL shape while table bodies retain their indentation.Closes #2747